Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/743

Internet Message Format | 1994-08-27 | 11KB

From: [e-mail]
From: Goemon <[e-mail]>
From:     Lexicor
Date: Mon, 11 Jul 1994 12:21:08 -0400 (EDT)
Date: Mon, 11 Jul 94 2:18:57 EDT
Subject: Gem List (fwd)
Subject: Gem List
Subject:  Re: Gem Listing (fwd)
Subject:  Re: Gem List (fwd) from goemon
Subject:  Re: Gemlist
Subject: App_defs.sys
Date: Mon, 11 Jul 1994 12:21:08 -0400 (EDT)
Mime-Version: 1.0
Precedence: bulk

Forwarded message:
>From [e-mail] Mon Jul 11 02:19:03 1994
From: Goemon <[e-mail]>
Message-Id: <[e-mail]>
Subject: Gem List
To: [e-mail]
Date: Mon, 11 Jul 94 2:18:57 EDT


To: Gem List
Subject:  Re: Gem Listing (fwd)

]The only time this will happen is when the application is topped. If it's
]not topped, then a click in one of the windows will send an event to
]the app to "wake up".
]
]Even so, the overhead is *miniscule*. I've got it in my head to write a
]benchmark program to compare overheads of different methods, and put this
]argument to rest permanently.

>You're missing the point.  If the OS has a large rectangle to compare
>against, and the mouse moves, it only has to check a few numbers.  ONLY
>when the OS finds the pointer entering or leaving the rectangle does it
>have to go back to your program.

You forget that the CPU generates an interrupt every time the mouse moves
anyways. Simply moving the mouse on a normal ST can take up to 25% of
CPU time. The time that objc_find uses is minscule in comparison. I don't
see a problem here :-)

Programs that are running in the background will only be receiving a
fractional amont of the events anyways -- only things like timer events
and such. The topped application *ALWAYS* gets event priorities.
And if you think about it, this makes sense. You want the topped application
to be as responsive as possible, and for the background apps to receive
the remaining cpu time available.

>If you use a 1-pixel rectangle, then EVERY mouse movement goes back to
>your program, and your program has to do an objc_find, EVERY TIME.

We're not using "1 pixel rectangles" like you seem to enjoy saying alot :-)
You can get the current mouse pointer coordinates by any method you like --
as you will see in the example code, that part was specifically left "open".

You are perfectly free to get the mouse coords with any method you like.
If you want to make your life difficult by walking internal trees yourself,
go ahead. It's your sanity at stake, not mine. However, the effort required
to do this, and the *minimal* amount of CPU time it would save (if any) is
not worth it.

>In a single-tasking environment, it doesn't matter which you do, but in a
>multitasking environment, the OS having to go back to your program for
>EVERY mouse movement creates a tremendous amount of overhead that is very
>wasteful.  Compare running your code for every 1 mouse movement to
>running your code for every 20 mouse movements.

You have to understand how GEM works before you can bring up an argument
like this. The fact is that not every application will get a mouse event
unless they write their own mouse routine (not everyone is willing to do :-).

With most programs you have to have the application TOPPED in order to
receive ANY type of mouse related events, and in this case it also makes
sense. Why watch mouse events for a background window? You try writing a
program that will get mouse events in the background and find out how
difficult it is. :-) You would have to watch every event that comes through
AES for *ANY* program, and decipher whether it's for you or for some other
application. That's why nobody does this. It's just a pain in the ass, and
not worth the effort.

It doesn't have to go back to our program for every mouse movement. In fact,
it CAN'T unless the application is topped.

>The OS code has to run every time, but your code doesn't because it only
>needs to know about certain entries/exist, and to call your EXTRA CODE
>repeatedly to do nothing but realize that it needn't do anything is wasteful.

There is another problem here -- our library allows you to set multiple
timer events and 'attach' them to windows. If we set our event_timer to
wait for rectangle events, then the timers would become effectively
useless. The library does need to do events on a regular basis, but only
mouse events will be done if the application is TOPPED.

This message thread is getting rather old, and I *STILL* don't understand why
we're arguing about this. It doesn't make any sense at all, so I'm dropping
the issue now.

-Goemon
-----
Subject:  Re: Gem List (fwd) from goemon

Warwick:
--------
I think you misunderstood the nature of the program I was coding in the first
place.  I am using a method of task-switching multitasking timers in my
GUI library, and if I were to do the method YOU have been talking about,
the timers would stop.  No matter what is the case, I will still have to
"busy-wait" as you called it.  There is no other alternative, unless you
wish for the timers to come to a halt until the mouse exits a rectangle.

>>That's the problem.  Not all GEM libraries are the same.  Why not use
>>Extended Object Types?
>Because GEM++ can support thousands of different object types.  It focusses
>on behavioural objects rather than visual objects (eg. there are no different
>types of visual radio buttons - just the std GEM ones), so there is no gain
>in the WYSIWYG of RSC editing.

Warwick, are you SURE you understand what Extended Object Types are?  From
the way you speak, it sounds like you have no idea why they were designed.

Extended object types can *easily* handle behavioural objects. Just look
at WinLIB PRO's active sliders. Those are just normal everyday sliders, with
the one addition that their extended object type is different.

You're saying that with Gem++ you would have to add code to support the
active slider, perhaps doing something like "register_active_slider(TREE,
object, orientation);" which is insane. Having to write code to support
an interface when the interface should do those things ITSELF is a pain.

Besides the fact that if you want to change the functionality of a button,
you can't do it visually, you have to do it programatically. This is right
along the lines of insanity that MultiTOS did when they forced you to do
heirarchical menus by linking them together within your code, rather than
the *obvious* way of allowing you to design heirarchical menus using
a resource editor.

If you want to make a quick change to your interface, with Gem++ you would
have to recompile the code. With all other libraries it's just a quick dip
into a resource editor to make that change.

To me, this seems like an *ENORMOUS* disadvantage of Gem++, as it is with
MultiTOS. A library is supposed to make coding easier, not more difficult.

Is it any wonder why nobody has used Gem++ for anything yet? :-)

-- Ken Hollis
(Bitgate Software)
-----
From:     Lexicor
Subject:  Re: Gemlist

Yat:
----
>    you subscribed as [e-mail] is that correct? Well
>no wonder the gem-list bounces your email from venice, as you are not
>subscribed to venice.
Then register [e-mail], dammit! :-)

-- Ken Hollis
(Bitgate Software)
-----
Subject: App_defs.sys

> > Now look deeper into the problem.  Say, 50% or programmers support the
> > App-defs file and 50% of the apps only use the level #1 standard.  A user
> > could then have most of his apps configurable, and he can change those
> > keys, but if he changes from the defaults, the other half of his
> > applications will not use the same keyboard short-cuts!!  This is not _A_
> > standard as it creates TWO incompatible standards.  The only way the
> Yes. The app-defs file must be either abandoned or made compulsory. I'm
> inclined to agree with you but the problem with this is that lazy programmers
> will ignore it and just stick with the Atari standard shortcuts, with the same
> problems as if both standards were allowed.

> > beyond the scope of the GEM-List.  The GEM-List only supplements ATARI's
> > documentation.
> And replaces part of it. Bu